When writing this I saw LDoc's @tparam tag to dictate a parameter of a specific type. But in your case I think @param is being used the same way. I'd say we may need the user to tell if @param [name] is being used as @param [type] [name] like in your case. We can do that later and see if this behaviour works first.

Attempting to infer types, however, I can't seem to get this to actually do anything.

In Transformer#transformParameterDeclaration it tries to determine the type of the parameter by searching through all tags related to the function, but only @tparam, not @param.

If the getParameterTParam could be changed to getParameterType(node: luaparse.Identifier | luaparse.VarargLiteral, availableTags: ldoc.Tag[]): { diagnostics: string[]; type: string } we could reduce the size of transformParameterDeclaration and have a more concrete function to determine a parameter type.

As for debugging, there is no real workflow 😛. At the moment I just use VSCode and open up a special terminal that spies on NodeJS processes you execute so you can debug within VSCode. Otherwise you could use the debugger statement (debugger;) to breakpoint the program.

Oh and same thing for @return, the program is looking for @treturn at the moment, but since it could be one or the other, getReturnType(node, availableTags) could be created instead

Thanks for the info!

Even more sinister, I am trying to make a fuzzy matcher from the @param and @return tags in the program.

The nakama library I am consuming will have comments like:

-- @param match_id The match id string.

So I am just looking for any type keyword in the description and assuming it is the type of the param. As there are sometimes hints to what type might be in the param.

Could be useful to pass a --fuzzy option to the program and then let it try real hard to scrape type hints so you don't just have 10k any in the program, but could also produce false positives.